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The invention relates to a firamework for a tdeconununication system controller to 
apply application or control logic to telecommunication services, and to a controller 
incorporating such a framework, 

10 

Prior Art Discussion 



Heretofore, the approach to developing such controllers has been to ^rnk the software 
very closely to the hardware resources so that a fiast response time is achieved for real 
15 time control. However, this approach does not allow for a sigmficant level of 
modification of either the control logic or the resources which implement the 
telecommimication services. 

Obf ects of the Invention 

20 

Therefore, it is an object of the invention to provide a controller which provides 
excellent flexibility for modifying the control logic and the resources in a manner 
which does not sacrifice controller speed performance. 

25 SUMMARY OF THE INVENTION 

The invention provides a telecommunication controller comprising a control 
framework comprising:- 
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an application domain level operative according to control logic domain 
objects; and 

a meta level operative according to meta objects which represent the domain 
object classes, and provide an interfece to isolate the domain objects from 
services associated wiA the controller. 

Because the meta level represents the domain object classes, domain objects may be 
added, deleted, or modified without the need to directly notify other domain objects. 
The meta level effectively tracks the structure of the domain objects. Also, because 
the meta level interfaces with the telecommunication services, modifications to the 
services may be implemented transparendy to the domain objects. 

In one embodiment, the meta objects comprise event channels for automatic 
notification to subscribers. 

Preferably, the meta objects are structured in a heirarchy of abstract dasses for 
declaring action and attributes. 

In one embodiment, the meta objects comprise means for invoking actions on 
domain objects and changes to attributes of domain objects. 

In another embodiment, the controller comprises a key class naming objects in the 
domain level. 

Preferably, the meta level defines containment of domain level objects and the 
domain level objects and the domain level comprises means for automatically 
notifying the meta level of containment modifications. 
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In another embodiment, the meta objects comprise means for interrogating a base 
object containment hierarchy to locate a required object in response to a request from 
a requesting objea. 

In a further embodiment the meta objects comprise means for performing persistence 
data operations transparendy to the domain objects. 

In another embodiment, the meta objects comprise means for updating a data 
backup controller for fault tolerance transparently to the domain objects. 

Preferably the meta objects comprise means for verifying base object proposals to 
update real resource attributes. The meu objects may comprise means for publishing 
events on channeb to notify adapter objects. 

In one embodiment, the adapter objects are contained in a services level in the 
controller. 

DETAILED DESCRIPTTON OF THE INVENTIQN 
Brief Description of the Drawings 

The invention will be more clearly understood bom the following description of 
some embodiments thereof, given by way of example only with reference to the 
accompanying drawings in which:- 

Fig. 1 is a schematic representation of a control framework of a controller of 
the invention; 

Fig; 2 is a diagram illustrating signal transfers for setting an attribute in a meta 
level; 
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Fig. 3 is a diagram illustrating signal transfers for creating a domain object; 
Fig. 4 is a diagram illustrating attribute classes; 

Fig. 5 is a signal transfer diagram for getting an attribute from the meta level; 

Fig, 6 is a diagram illustrating action dasses in the meta level; 

Fig, 7 is a diagram illustrating invocation of an action from a meta object; 

Fig. 8 is a signal transfer diagram for setting a key; 

Fig. 9 is a diagram showing containment classes; 

Fig. 10 is a diagram showing a simple example of domain level contaiimient; 

Fig, 11 is a diagram showing chained contained information classes for a 
domain level tree; 

Fig 12 is a signal transfer diagram showing declarations for shelf and slot 
domain objects; 

Fig. 13 is a diagram showing signal transfers for setting an attribute; 

Fig. 14 is a signal transfer diagram showing an operation for loading an objea 
from penistent storage; 

Fig 15 is a diagram showing signal transfers for creating an objea from 
persistent storage; and 
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Fig 16 is a diagram showing setting of an attribute on a resource. 
Descriptinn nf rhp EmbndiTTKTif*! 

Referring to Fig. 1. the structure of a telecommunication controUer I is iflustrated. 
The controller 1 is in this embodiment for an asynchronous transfer mode (ATM) 
system which performs conversion between ATM and time division multiplex 
(TDM) formats. However, the structure may be used for any telecommunication 
controller which needs to perform in real time and which is programmed to control 
resources which provide the required services. The controller 1 comprises a base or 
domain level 2 and a meta level 4. The meta level 4 communicates with horizontal 
services 10 which may or may not be part of the controUer 1. The base level 2 
comprises domain objects (DOS) 3. The meta level 4 comprises meta objects 5. The 
15 horizontal level 10 comprises adapter objects 11 for resources, persistence, fault 
tolerance, and text 

The meta level 4 provides a representation of the structure of the base level objea 3. 
The important information which the meta level provides indudes:- 



20 



25 



infbnnation regarding attributes and actions for the domain objea classes, 
object containment configurations, and 

which attributes are persistently stored, fault tolerant (replicated), and which 
are represented on real resources.. 



As an example of die role of the meta level, complex services such as downloading of 
the information in an objert to hardware can be written using die meta level. The 
30 meta level aUows telecommunication services to be added, deleted or modified 
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without the need to re-program the base lev el, and likewise the base level code may 
be changed without the need to modify die services. 

The structure of the controller 1 is best described with reference to illustrative 
examples. Referring to Fig. 2, a slot object 3 accesses a corresponding meta object 5, 
which in mm accesses a resource attribute adapter 11. Application code calls the 
setLineCoding method on the slotDO domain object. This function informs the 
meta level calling the setForBaseLevel on the meta attribute. The meta attribute 
verifies that the new value can indeed be changed. If, for example, the attribute 
represents a value on a hne card, the. real resource aspea of the meta object would 
have provided a verification strategy object to die meta attribute. In this case, the 
verification strategy object would try setting the attribute on that line card. If the 
verification failed for some reason, the meta attribute would stop and return an enor 
status to the domain object. If the verification is positive (i.e. the line card has been 
updated) the meta attribute updates the raw data storage on the base level and then 
informs any subscribers it has for changes to the attribute by pushing an event mto an 
event channel for the attribute. This notifies subscribers such as a persistent attribute 
adapter, which can store the new attribute value in the persistence storage layer 
(PSL). 

More generally, domain objects are described in an information model and examples 
include Card, Slot, and ATMInterface. The domain objects are generally 
implemented as standard C++ objects. They have get/set methods for attributes and 
any significant application logic is implemented in logic. These methods may use 
methods on other domain objects and they can create their contained objects and 
may contain states and state machines, and support alarm condirions. The domain 
objects invoke services on the meta level. However, the meta level also invokes 
services on the base level. 
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Referring now to Fig. 3. another example of the base level invoking the meta level is 
a parent object aeating a contained objea. The parent object creates the contained 
object and ixiforms die meta level of tfus new object This is done using the 
' notifyCreate command which in turn causes the meta level to store the object and its 
5 attributes and to notify the persistence adapter. In general, there are three phases to 
creating an object as follows 

construction, in which the object is allocated, 

10 initialisation in which the object is fully set up, and 

notification in which the meta objea is notified. 

These three phases are generally controlled by the parent containing object. 

15 

Regarding the meta level, there is one meta object per dass of domain objects. The 
meta objects are singletons and are containers for other objects which describe the 
domain object class. The meta objects contain attributes and actions and dass 
"aspects" such as containment, persistence, agent interfacing, and fault tolerance 
20 information. The meta objects also contain event channels which are informed when 
an instance of a dass is created. They are subscribers and so can learn of instance 
creation and deletion using these channels. Fig. 3 shows an example of diis in which 
a meta objea is notified of an objea creation. 

25 Attributes are contained in the meta objects 5. Attributes can be get/set from the 
meta level as well as from the base levd. Referring to Fig. 4, attribute dasses are 
illustrated. 



30 



Referring to Fig. 5. getting an attribute from a meta objea may be performed by 
application code signalling the meta objea, in mm accessing the domain objea. 
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Referring to Fig, 6, meta actions are declared using a hierarchy of abstract classes to 
avoid using much code in header files. The concrete implementations of actions 
. (typically just used in implementatioh of meta objects) take fimction pointers to the 
5 corresponding methods on the base level domain classes, as illustrated in Fig. 7. In 
general, meta actions support die domain concept of actions on a domain object 
They are informed when the base level is running an "action". They can also run 
the action from the meta level, for example for an action invocation from the client, 
an action request from the agent interface, or an action invoked by a conmiand from 

10 the line card to the controller. Actions are contained in meta objects and contain 
meu information. The MetaAction run method takes an instance reference, which is 
used to call die base level fimction. It also takes a single const input reference and a 
single non-const output reference. If multiple input or output parameters are 
required then they are groomed into a single struct. By invoking actions through the 

15 meta layer, fimctionality generic to all actions is performed, such as replication, and 
providing debug information. 

Referring now to Fig. 8, keys are simple classes which represent the information 
needed to uniquely identify an instance of a class. For example, a key for a shelf 
20 class may be as follows; 



class ShelfKey 
{ 

public: 
25 unsigned shelfNum; 

const unsigned & getldentO const 
{ 

return shelfNum; 

} 

30 void setldent (const uhsigned& newldent) 
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shelf Num = newldent; 

} 

}; 

in fliis example, the shelfNum in the key will uniquely identify a shelf instance. The 
getldent and the setldent functions are used in die Containlnfo code in the 
framework. These functions must not be virtual. The keys are made of inheritance 
chains. If an object of a class can be contained in objects of another class, tiien the 
key of that dass will inherit from its containers key dass. In die following example, 
Slot is contained in die shelf 



Class SlotKey : public ShelfKey 
{ 

15 public: 

unsigned slotNum; 

const unsigned^ getldent () const 
{ 

return slotNum; 

20 } 

void setldent (const unsigned& newldent) 
{ 

slotNum = newldent; 

} 

25 } ; 



The keys are stored in "dosed to change" packages. A key can be used to find an 
instance of a domain object. This behaviour is supported from the meta level 
containment information, as illustrated in Fig. 8. The opposite scenario may also 
30 happen, in which an instance can set a key value. To do this, the instance sets the 
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part of the key it undentands. It needs its parent objea to set the rest of the key, and 
so on up tfie tree. 

In addition to the meta level providing information on domain object actions and 
5 information, it also provides containment information. The containment 
information of the meta level provides the foUowing functionality: 

- finding a domain objea using a stream representation of its identity. 



10 



creating a new domain otgect identified by a string representation of its 
identity, 



- creating an iterator for instances of the domain class, and 

1 5 - finding an object based on a key representation of its identity. 

The "contain info" needs to know information such as the string representation of 
the class name, and this is obtained firom the meta object. It also needs the 
containment information from its container classes to perform some of its 
20 fimctionality. Accordingly, instances of containment information objects tend to be 
chained together in a way Aat reflects the containment tree Fig. 9 illustrates 
ContainlnfoClasses. 

There are a number of different concrete contaiim:ient information classes which 
25 implement the generic behaviour specified by the abstract ContainlnfoFor. 



Referring to Fig. 10, an example problem domain is illustrated in which there is a 
singleton representing the whole system, shelves are contained in the system, slots 
and fans are contained in a shelf, and cards are uniquely contained in a slot. 
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Referring to Fig. II, ChainedContainlnfo classes for the above problem domain 
contammeni tree are iUustrated. The ShelfMeta contains the 
SingleParentContainlnfoFor. It also contains ContainlnfoAdapers for its two types 
of contained objects. 

The meta level dasses for containment need to use fedlities implemented by the base 
level. These facilities are defined in die following two abstract classes:- 

- ContainerOf - specifies the dass is a container of anodier type of object 
Means findObject, findFirstObject and findNextObject, aU taking an 
identifier, must be implemented. 

- ContainerOfUnique - specifies ±e dass is a container of a unique object. 
Means findObject taking no identifier must be implemented. 

Referring to Fig. 12, the class dedaxations for the domain objects shelf and slot are 
illustrated. A combination of the parent and containment information is used to 
send the identification of an object instance to a stream. 

Some of the attributes of the domain objects need to be persistently stored and this is 
handled by a meta object The meta object contains an "AbstractPersistObject" 
adapter in the same way. The AbstractPersistObject provides interfaces whereby it 
can load all objects of a dass from persistence and can subscribe to object creations 
and deletions. It also contains AbstractPersistAttr objects which are created for each 
attribute which is persistent. 

Referring to Fig. 13, the declarations for setting an attribute are illustrated. The 
AbstractPersistAttr subscribes to changes in the meta attribute and persistendy stores 
the new values when changes do happen. A mechanism for loading an object from 
persistence storage is illustrated in Fig, 14. 
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In the example illustrated, the contain info is passed the whole stream. It finds the 
container and calls makeObject on. If the whole operation was successfiil a new 
object is returned. This is then initialised using the storage from the persistence 
layer, finally the notifyCreate is called on the meta level. 

Fig. 15 shows creation of an object from persistent storage. 

The meta level is also used for keepmg track of and updating real resources. 
Typically, there are proxy objects for interacting with objects on the real resource. 
There are two scenarios:- 

(a) When the attribute is set the real resource must try to set the value first. 
This results in talking to a middleware proxy. If this works, the rest of the 
process of setting an attribute is run. 

(b) If the real resource needs to be configured from the controller, in this case 
all of die real resoturce attributes need to be downloaded to the hardware. 
An action means calling a proxy fimction on the real resource, the proxy 
function can be called and retiim-checked in the base object function. If 
an attribute is read-only on the hardware and it can change autonomously, 
the get function in the domain object can call the proxy direcdy to get the 
value from the hardware. 

A medianism for setting an attribute on a real resource is illustrated in Fig. 16. 

The meta level also provides an agent interface to the base objects for the agent sub- 
system. Some attributes may not be visible on Ae agent interface or ±ey may be 
more restricted in their scope i.e. read-only instead of read/write. 
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Two other aspects of base objects and their representation as meta objects are 
polymorphism and text interfaces. Polymorphism is where there is a base class 
domain object from which derived classed are to be inherited, the derived classes 
want to add new attributes and actions and so wifl have extra meta information as 
well as the information from the base dass. 

The text interface provides facilities for representing objects and attributes as text 
strings. It is used by the CLI software. 

The meta-Ievel architecture may also support domain object versioning. 

It win appreciated that the mvention allows appUcation code and logic to be 
independent of the apphcation level services. This means diat changes to services 
can be made widiout affecting the general application logic, avoiding sweeping 
changes to the software system. These advantages have been achieved with a very 
simple and well defined interfaces between the base and the meta level. 

New functionality can be added to the system without aflfecting the application code 
because most of tiie persistence, real resource interface, text interface, and auditing 
functionality can be written in terms of the meta level. Likewise, services may be . 
modified wiriiout aflFecting the control logic. 

The invention also achieves a high level of reuse and qualification of the system is 
simplified. 

The invention is not limited to the embodiments described but may be varied in 
construction and detail within the scope of the daims. 
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Qaims 

1 . A telecommunication controller comprising a control framework comprising:- 

an application domain level operative according to control logic domain 
objects; and 

a meta level operative according to the meta objects which represent the 
domain object dasses and provide an interface to isolate the domain objects 
from services associated with flxe controller. 

2. A controller as claimed in daim 1, wherein the meta objects comprise event 
channels for automatic notification to subscribers. 

3. A controller as claimed in any preceding claim, wherein the meta objects are 
structured in a hierarchy of abstract dasses for dedaring actions and 
attributes. 

4. A controller as claimed in any preceding claim, wherein the meta objects 
comprise means for invoking actions on domain objects and. changes to 
attributes of domain objects.. 

5. A controller as claimed in any preceding daim, wherein the controller 
comprises a key dass naming objects in the domain level. 

6. A controller as claimed in any preceding claim, wherein the meta levd 
defines containment of domain level objects and the domain level comprises 
means for automatically notifying, the meta level of containment 
modifications. 
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7. A controDer as claimed in cdaim 6, wherein the meta objects comprise means 
for intenogating a base object containment hierarchy to locate a required 
object in response to a request from a requesting object 

8. A controller as claimed in any preceding daim, wherein the meta objects 
comprise means for performing persistence data operations transparendy to 
the domain objects. 

9. A controller as claimed in any preceding claim, wherein the meta objects 
comprise means for updating a data backup controller for feult tolerance 
transparently to the domain objects. 

10. A controller as claimed in any preceding claim, wherein the meta objects 
comprise means for verifying base object proposals to update real resource 
attributes. 

11. A controller as claimed in claims 8, 9, or 10, wherein the meta objects 
comprise means for publishing events on channels to notify adapter objects. 



12. 



A controller as claimed in daim 1 1 , wherein the adapter objects are contained 
in a services levd in the controller. 



Abstract 



A telecommunications system controller framework (1) has application domain base objects (3) 
in base level (2), and a meta object (5) associated with each base object class. The raeta level 
deals with containment, persistence data, and real resources. The meta objects (5) represent 
domain object classes. They also isolate the domain objects from services. The meta objects (5) 
have event channels for automatic notification to subscribers such as adapter objects in a services 
level. 
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